Memo functions, polytypically! 



Ralf Hinze 

Institut fur Informatik III, Universitat Bonn 
Romerstrafie 164, 53117 Bonn, Germany 
ralf @inf ormatik . uni-bonn . de 
http : //www. informatik. uni-bonn. de/ "ralf / 



Abstract. This paper presents a polytypic implementation of memo 
functions that are based on digital search trees. A memo function can 
be seen as the composition of a tabulation function that creates a memo 
table and a look-up function that queries the table. We show that tabu- 
lation can be derived from look-up by inverse function construction. The 
type of memo tables is defined by induction on the structure of argu- 
ment types and is parametric with respect to the result type of memo 
functions. A memo table for a fixed argument type is then a functor and 
look-up and tabulation are natural isomorphisms. We provide simple 
polytypic proofs of these properties. 



1 Introduction 

A memo function [11] is like an ordinary function except that it caches previ- 
ously computed values. If it is applied a second time to a particular argument, it 
immediately returns the cached result, rather than recomputing it. For storing 
arguments and results a memo function internally employs an index structure, 
the so-called memo table. In fact, a memo function can be seen as the composi- 
tion of a tabulation function that creates a memo table and a look-up function 
that queries the table. The memo table can be implemented in a variety of ways 
using, for instance, hashing or comparison-based search tree schemes. These ap- 
proaches, however, have their drawbacks if the argument to a memo function is 
a compound value such as a list or a tree. Since comparing compound values 
is expensive, search tree schemes based on ordering are prohibitive. Hash tables 
are no viable alternative as hashing compound values is difficult. Furthermore, 
in case of collisions values must be checked for equality (though a hash-consing 
garbage collector [1] may alleviate this problem). For memo functions with com- 
pound argument types digital search trees, also known as tries, are the data 
structure of choice. Looking up a value in a trie takes time proportional to the 
size of the value. In particular, the running time is independent of the number of 
memoized values. In combination with lazy evaluation tries provide an elegant 
and efficient implementation of memo functions. 

This paper is a direct descendant of my earlier work on generalized tries [5] , 
which in turn relies heavily on the framework of polytypic programming [7, 6, 8]. 
The central insight is that a trie can be considered as a type-indexed datatype 
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that is defined by induction on the structure of types. The look-up function 
then enjoys a straightforward polytypic definition. We show that from this defi- 
nition one can systematically derive its inverse, the tabulation function. Like the 
functions involved the derivation is parametric in the underlying datatype, the 
argument type of memo functions. Note that the work reported here generalizes 
the approach of [5] in that we define tries for arbitrary datatypes of arbitrary 
kinds (the precursor was restricted to types of first-order kind). A second, but 
minor difference is that for memo tables we require infinite tries whereas [5] was 
concerned with finite tries. 

The rest of this paper is structured as follows. Section 2 briefly reviews the 
paradigm of polytypic programming. Section 3 gives polytypic definitions of 
memo tables and associated look-up and tabulation functions. The naturality of 
these functions is shown in Section 4. Finally, Section 5 concludes and points 
out a direction for future work. 

Examples are given in the functional programming language Haskell 98 [14]. 
Throughout, we use Haskell as an abbreviation for Haskell 98. 

2 Polytypic programming 

This section briefly reviews the concept of polytypic programming. For a more 
thorough treatment the interested reader is referred to [7,6,8]. The cognoscenti 
may safely skip this section. 

The central idea of polytypism is to provide the programmer with the ability 
to define a function by induction on the structure of types. Since types play 
a central role in this undertaking, let us first take a closer look at Haskell's 
type system. Haskell offers one basic construct for defining new types: datatype 
declarations. A data declaration takes the following general form: 

data D xi ... x m = K x tn ... t lmi | • • • | K n t nl ... t nmn . 

Here, D is the defined type constructor (the are value constructors). From 
the perspective of language design the data construct is quite a monster as it 
comprises no less than four different features: type recursion, type abstraction, 
n-ary sums, and n-ary products. Thus, Haskell's type system is covered by the 
following language of types (we do not consider functional types, that is, no 
higher-order memo functions yet, but see Section 5). 

type variables a, b 

type terms t, u ::= 1 | (t + u) \ (t x u) \ a \ (t u) \ (Aa.t) \ (pia.t) 

Here, 1 is the unit datatype, t u denotes type application, Aa.t denotes type 
abstraction, and ^a.t is the least fixpoint of Aa.t. Not every type term denotes 
a sensible type, consider, for instance, 1 1. To exclude these terms we require 
type terms to be well-kinded, where the language of kinds is given by 



kind terms K, L ::= * | K — > L 
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Here, V is the kind of manifest types such as 1; K — > L is the kind of type 
constructors that map type constructors of kind K to those of kind L. The 
straightforward typing rules (or rather, 'kinding' rules) are omitted for reasons 
of space, but see [6,8]. Now, given this type language we can easily translate 
data declarations into type terms: the type D defined above becomes 

[iD.Axi Ax m .(hi x • • • x t lmi ) H h (t nl x • • • x t nnin ) , 

where t\ x • • • x tu = 1 for k = 0. For simplicity, n-ary sums are reduced to 
binary sums and n-ary products to binary products. 

Though the type language is quite complex, defining a polytypic value is 
comparatively simple. It suffices to specify cases for the three primitive type 
constructors 1, '+' and 'x'. We treat these type constructors as if they were 
given by the following datatype declarations. 



Example 1. The polytypic equality function is defined by the following equa- 
tions. For clarity, the type argument is enclosed in angle brackets. 



equal (t + it) (Inl x±) (Inl X2) = equal (t) X\ X2 

equal(t + u) {Inl x\) {Inr y 2 ) = False 

equal(t + u) {Inr y\) (Inl X2) = False 

equal(t + u) {Inr yi) {Inr y 2 ) = equal(u) y\ y 2 

equal(t x u) {x 1 , yi) (x?, y 2 ) = equal(t) x x x 2 A equal(u) y x y 2 

Since 1 has only one proper element, equal(l) x y trivially yields True. Elements 
of a sum are equal if they have the same constructor and the arguments of the 
constructor are equal. Finally, pairs are equal if the corresponding components 
are equal. □ 

It may seem surprising at first sight that a polytypic function such as equal is 
completely determined by giving cases for the three primitive type constructors. 
However, using standard reduction rules for type terms, that is, {Aa.t) u = 
t [a:=u] and /ia.t = t [a := fia.t] every type term of kind * can be reduced to a 
term of the form 1, t + u, or tx u, which are exactly the cases covered by equal. 

Example 2. The type of natural numbers is given by 

data Nat = Zero \ Succ Nat . 

Using equal we can test two naturals for equality. 

equal(Nat) {Succ Zero) {Succ Zero) = equal(l + Nat) {Succ Zero) {Succ Zero) 



data 1 =() 

data a + b = Inl a \ Inr b 

data a x b = (a,b) 



equal(a) 
equal(l) x y 



a — > a — > Bool 
True 



= equal (Nat) Zero Zero 
= equal (1 + Nat) Zero Zero 
= True 
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Note that Zero equals Inl () and Succ n equals Inr n. □ 

The example suggests a simple way of implementing polytypic functions: if types 
are represented by an algebraic datatype (covering the cases 1, '+' and 1 x '), then 
equal can proceed by ordinary pattern matching. Alternatively, one can specialize 
or partially evaluate a polytypic value for a given closed type term. This has the 
advantage that passing representations of types at run-time is not necessary. 
The key idea for a compositional definition of equal is to mimic the structure of 
types on the value level. Consider, for instance, the specialization of equal(t u). 
How can we define equal (t u) compositionally in terms of specializations for the 
constituent types, equal(t) and equal(u)? Now, since t is a mapping on types, 
the idea suggests itself that equal(t) is a mapping on equality functions. Then 
equal(t u) is given by the application of equal(t) to equal(u). In a nutshell, type 
abstraction is mapped to value abstraction, type application to value application, 
and type recursion to value recursion. 

Example 3. The following equations extend the definition of equal given in Ex- 
ample 1 (note that equal a is a fresh variable associated with a). 

equal (a) = equal a 
equal (t u) = (equal (t)) (equal (u)) 
equal(Aa.t) = X equal a . equal (t) 
equal(na.t) = fix (X equal a . equal (t)) 

Here, fix is the fixpoint operator on the value level. Note that equal's type 
argument is no longer restricted to types of kind *. For that reason we must 
generalize its type signature: 

equal(a :: K) :: Equal(K) a , 
where Equal(K) is defined by induction on the structure of kinds. 

Equal(*) t = t -» t -» Bool 

Equal(K -> L) t = Va.Equal(K) a -» Equal(L) (t a) 

As an example, Equal{* -> *) F = Va.(a -> a -» Bool) -> (F a -» F a -» Bool). 
Given these definitions we can specialize equal for Nat = [in.l + n. 

equal Nat = fix (Xequal n . equal + equal x equal n ) 

where equal x = equal(l) and equal + = equal(Xa.Xb.a + b). If we remove the 
abstract clothing, we obtain the familiar Haskell function 

equalNat :: Nat ->■ Nat ->■ Bool 

equalNat Zero Zero = True 

equalNat Zero (Succ n?) = False 

equalNat (Succ rii) Zero = False 

equalNat (Succ rii) (Succ n^) = equalNat ri\ ri2 □ 

It is worth noting that the development is by no means special to equal. Rather 
it works for arbitrary polytypic values that are indexed by types of kind *. 
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3 Memo functions 

In this section we apply the framework of polytypic programming to implement 
trie-based memo tables with associated look-up and tabulation functions. 

Table(k ::*)::* — > * 

apply (k) :: Vv .Table(k) v — > (k — > v) 
tabulate(k) :: Vu.(fc -»«)-» Table(k) v 

The type Table(k) v represents memo tables that are indexed by values of type k 
and store values of type v. In Section 3.1 we show how to define Table by in- 
duction on the structure of k. The function apply (k) is the associated look-up 
function: it takes a memo table and a key of type k and returns the associated 
value of type v. Its converse, tabulate (k), tabulates a given function with ar- 
gument type k. Given this interface we can easily memoize a function of type 
k — > v: 

memo(k) :: \/v.(k — > v) — > (k — > v) 
memo(k) <p = apply(k) (tabulate(k) ip) . 

The memoized version of <p is simply memo(k) (p. It is worth noting that this 
technique depends in an essential way on lazy evaluation: if the type of keys is 
infinite, then tabulate(k) if produces a potentially infinite tree. We also require 
full laziness so that tabulate(k) if is evaluated only once even if it is queried 
several times. Haskell meets both requirements. 



3.1 Memo tables 

Tries, or rather, generalized tries [4] enjoy a firm mathematical foundation: they 
are based on the Jaws of exponentials. 

1 — > v — v 

(h + k 2 ) -5- v = (h -> v) x (k 2 -> v) 
(ki x k 2 ) -> v = h -> (& 2 -> v) 

Note that the last equation captures the idea of currying. From these equations 
we can immediately derive a polytypic definition of Table. 

Table (1) v =v 

Table {h + k 2 ) v = Table (h) v x Table{k 2 ) v 
Table {h x k 2 ) v = Table (h) (Table{k 2 ) v) 

The type constructor Table(k) has kind * — > *. In fact, we will see in Section 4 
that Table(k) satisfies the properties of a functor. In particular, the trie for the 
unit type is the identity functor, the trie for sums is a product of functors, and 
the trie for products is a composition of functors. 
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To specialize Table(k) for a given type term k we can apply the techniques 
sketched in Section 2 (though the techniques have been developed for type- 
indexed values they work equally well for type-indexed types). The following 
equations extend Table to arbitrary type terms of arbitrary kinds. 

TABLE (*) = * -» * 

TABLE (K -» L) = TABLE(K) -» TABLE(L) 

Table (k :: K) :: TABLE {K) 

Table (a) = table a 

Table (t u) = (Table {t)) (Table(u)) 

Table(Aa.t) = Atable a . Table (t) 

Table (fia.t) = fxtable a . Table (t) 

Note that the kind of Table(k) depends on the kind of k. Consequently, TABLE 
is a kind-indexed kind. 

Example 4- The memo table for the type of natural numbers 

data Nat = Zero | Succ Nat 

is an infinite list. 

Nat = 1 + Nat 

Table(Nat) v = v x Table(Nat) v 

In Haskell notation Table (Nat) reads 

data TNat v = NNat v (TNat v) . 

If we replace NNat by Cons and add a case for Nil, we obtain the familiar type 
of lists (see Example 7). Note that this instance, the use of infinite lists for 
memoizing functions on the natural numbers, already appears in the paper on 
'The Semantic Elegance of Applicative Languages' by D. Turner [17]. □ 

Example 5. The following alternative definition of the natural numbers is based 
on the binary number system (using the digits 1 and 2). 

data Bin = End | One Bin | Two Bin 
The associated memo table is an infinite binary tree 

Bin = 1 + Bin + Bin 

Table(Bin) v = v x Table(Bin) v x Table (Bin) v 

and the corresponding Haskell type is given by 



data TBin v = NBin v (TBin v) (TBin v) □ 
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Example 6. The memo table for an unlabelled binary tree 

data Tree = Leaf | Fork Tree Tree 

has a somewhat mind-boggling type. 

Tree = 1 + Tree x Tree 

Table(Tree) v = v x Table(Tree) (Table(Tree) v) 

Note that the two occurrences of Table(Tree) on the right-hand side are nested. 
Indeed, the Haskell type TTree 

data TTree v = NTree v (TTree (TTree v)) 

is an example for a so-called nested datatype [3] . An element of type TTree v is 
like an infinite list except that the n-th entry has type TTree 11 v (a similar type 
appears in the seminal paper on nested datatypes [3]). □ 

Example 7. Finally, let us consider a parameterized datatype, the ubiquitous 
datatype of lists. 

data List a = Nil \ Cons a (List a) 

Since List is a type constructor, Table(List) is a 'higher-order' memo table that 
takes a trie for the base type a and yields a trie for List a. 

List a = 1 + a x List a 

Table (List) tablea v = v x tablea (Table (List) tablea v) 

The type constructor Table (List) is a so-called generalized rose tree. The corre- 
sponding Haskell type reads 

data TList ta v = NList v (ta (TList ta v)) □ 
3.2 Table look-up 

The look-up function is given by the following polytypic definition. 

apply (k) :: "iv.Table(k) v — > (k — > v) 

apply{l) t() =t 

apply(h + k 2 ) (h, t 2 ) (Inl «i) = apply(k x ) t x i x 

apply{h + k 2 ) (ti, t 2 ) (Inr i 2 ) = apply(k 2 ) t 2 i 2 

apply(h x k 2 ) t (h,i 2 ) = apply(k 2 ) (apply(h) t h) i 2 

The structure of apply becomes more visible if we swap the two value arguments 
(the new function is called lookup). 

lookup(k) :: \/v.k — > Table(k) v — > v 

lookup (1) () = id 

lookup (ki + k 2 ) (Inl ii) = lookup (ki) ii ■ outl 
lookup(k\ + k 2 ) (Inr i 2 ) = lookup(k 2 ) i 2 ■ outr 
lookup (ki x k 2 ) (ii, i 2 ) = lookup (k 2 ) i 2 ■ lookup (ki) i\ 
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Thus, on the unit type the lookup function is the identity, on sums it selects the 
appropriate memo table, and on products it composes the lookup functions for 
the components. 

The extension of apply works essentially as before. Applying the scheme of 
Section 2 we obtain 

Apply (*) u = Vv.Table(u) 

Apply(K -» L) u = \fa.Apply{K) a -» Apply(L) (u a) 

apply (k :: K) :: Apply (K) k 

apply {a) = apply a 

apply (t u) = (apply (t)) (apply (u)) 

apply (Aa.t) = Xapply a . apply (t) 

apply (fia.t) = fix (Xapply a . apply (t)) . 

There is one small glitch, however. Consider the type signature of apply (F) 
where F is a type constructor of kind * — > *. 

apply (F) :: V a. (V v. Table (a) v -» (a -» v)) -» (Vw. Table (F a) w -> (F a -> w)) 

The type signature contains two occurrences of Table. Of course, if we want 
to specialize apply (F) for a given F, we must specialize its type signature, as 
well. To this end we replace Table(F a) by Table(F) (Table(a)) and generalize 
Table(a) to a fresh type variable, say, ta. 

apply(F) :: \fta a.(Vv.ta v — > (a — > v)) 

->• (Mw.Table(F) ta w ->• (F a ->• w)) 

The following refined definition of Apply captures this generalization. 
Apply(*) tu u = \/v.tu —>(«—>«) 

Apply(K — > L) tu u = Via a. Apply (K) ta a — > Apply(L) (tu ta) (u a) 

It is not hard to see that Apply (K) (Table(k)) k is a valid type of apply (k :: K). 

Example 8. Querying a memo table for the natural numbers works as follows. 

applyNat :: Vv.TNat v -> (Nat -> v) 

applyNat (NNat tz ts) Zero = tz 

applyNat (NNat tz ts) (Succ n) = applyNat ts n 

Recall that elements of TNat are infinite lists. Consequently, applyNat corre- 
sponds to list indexing (written (!!) in Haskell). □ 

Example 9. The look-up function for binary numbers corresponds to tree index- 
ing (a binary number is interpreted as a path into a binary tree). 

applyBin :: Vv.TBin v — > (Bin — > v) 

applyBin (NBin tn to tt) End = tn 
applyBin (NBin tn to tt) (One b) = applyBin to b 
applyBin (NBin tn to tt) (Two b) = applyBin tt b □ 
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Example 10. The look-up function for memo tables of type TTree is somewhat 
hard to grasp. Its definition is, however, a simple instance of the general scheme. 

apply Tree :: V v. TTree v — > (Tree — > v) 

apply Tree (NTree tl tf) Leaf = tl 

applyTree (NTree tl tf) (Fork I r) = applyTree (applyTree tf I) r 

Since TTree is a nested type, applyTree requires polymorphic recursion [12]. □ 

Example 11. As the final example, consider the look-up function for lists. 

applyList :: \/ta a.(\/v.ta v — > (a — > v)) 

— > (Vw.TList ta w — > (List a — > w)) 

applyList applya (NList tn tc) Nil 
= tn 

applyList applya (NList tn tc) (Cons a as) 

= applyList applya (applya tc a) as 

Since List is a parametric type, applyList is a 'higher-order' look-up function 
that takes a look-up function for the base type a and yields a lookup function 
for List a. Note that applyList has a rank-2 type signature [10], which is not 
legal Haskell. However, recent versions of the Glasgow Haskell Compiler GHC 
[16] and the Haskell interpreter Hugs [9] support rank-2 types. □ 

3.3 Tabulation 

Tabulation is the inverse of look-up and, in fact, we can derive its definition by 
inverse function construction. For the derivation we use a slight reformulation of 
apply that allows for more structured calculations ('V' is the junk combinator, 
see, for instance [2]). 

apply (k) :: Vv.Table(k) v — > (k — > v) 

apply (1) t = XQ.t 

apply (ki + fe) t = apply (ki) (outl t) V apply (fe) (outr t) 
apply (ki x fo) t = uncurry (apply (ki) • apply (ki) t) 

We specify tabulate as the right inverse of apply. 

apply (k) (tabulate(k) ip) = tp 

Since we are seeking a polytypic definition of tabulate, we proceed by case anal- 
ysis on k. Case k = 1: 

apply(l) (tabulate(l) ip) = ip 
<^=^> { definition apply(l) } 

A(). tabulate (1) ip = <p 
<^=> { extensionality: ip\ = ip2 1 — > A ip\ ()= ip2 ()'■'■ A } 

tabulate(l) p = p () . 
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Case k = k\ + k 2 : let t = tabulate(ki + k 2 ) tp, then 

apply (ki + k 2 ) t = ip 
•4=> { definition apply (k\ + k 2 ) } 

apply{k\) (outl t) V apply(k 2 ) (outr t) = ip 
<^=> { coproducts: ip = ipi V ip 2 < ^=^ ip ' Inl = ipi /\ ip ■ Inr = ip2 } 

apply (ki) (outl t) = ip ■ Inl A apply (k 2 ) (outr i) = ip ■ Inr 
•£= { specification } 

outl t = tabulate(ki) (tp • Inl) A outr t = tabulate(k 2 ) (<p • Inr) 
•4=> { surjective pairing: z = (x\, x^) outl z = %\ A outr z = x 2 } 

t = (tabulate (ki) ((p ■ Inl), tabulate (k 2 ) ((p ■ Inr)) . 

Note that we use both the universal property of coproducts and the universal 
property of products (of which surjective pairing is a special case). Case k = 
ki x k 2 : let t = tabulate (ki x k 2 ) (p, then 

apply (ki x k 2 ) t = (p 
<^=> { definition apply (ki x k 2 ) } 

uncurry (apply(k 2 ) ■ apply(ki) t) = (p 
<^= { exponentials: uncurry (curry ip) = ip } 

apply(k 2 ) • apply(k\) t = curry (p 
<^= { specification } 

apply(ki) t = tabulate(k 2 ) ■ curry (p 
{ specification } 

t = tabulate(ki) (tabulate(k 2 ) • curry (p) . 

To summarize, we have calculated the following definition of tabulate. 

tabulate(k) :: Vv.(k -» v) -» Table (k) v 

tabulate(l) <p = ip () 

tabulate(ki + k 2 ) ip = (tabulate(ki) (tp ■ Inl), tabulate(k 2 ) (tp ■ Inr)) 
tabulate(ki x k 2 ) ip = tabulate(ki) (tabulate(k 2 ) ■ curry tp) 

The last equation becomes more readable if we convert it into a pointwise style. 
tabulate(ki x k 2 ) tp = tabulate(ki) (\ii. tabulate (k 2 ) (Xi^.tp (i\, i^))) 

The extension of tabulate to arbitrary type terms, which works exactly as for 
apply, is omitted for reasons of space. 
Two points are in order. 

First, the second calculation makes essential use of the universal property of 
coproducts. Alas, Haskell's natural semantic model, the category Cpo of pointed, 
complete partial orders and continuous functions, has no categorical coproduct. 
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In other words, in Haskell apply(k) (tabulate(k) tp) = p is only valid for so-called 
hyper-strict functions that completely evaluate their arguments. In the context 
of a lazy language this need for hyper-strictness is somewhat ironic. The intuition 
is that all information about the result of a memoized function is in the leaves 
of the corresponding trie. 

Note that an appropriate theoretical setting for the calculations is the cat- 
egory Cpo± of pointed, complete partial orders and strict continuous functions, 
which has categorical products (the cartesian product 'x'), categorical coprod- 
ucts (the coalesced sum '©') and is monoidally closed (the smash product '(g)' 
and the space 'o->' of strict continuous functions form a monoidal closure 1 ). 
Thus, memo tables are actually based on the following isomorphisms: 



lHt) = V 

(h © k 2 ) o-> v = (h o-^v)x (k 2 o-> v) 
(h ® k 2 ) o-> v = k\ o-»(& 2 o-> v) , 



where 1 = {_L, ()}. The isomorphisms make precise that memoization operates 
on strict functions but its implementation requires lazy evaluation: a trie for a 
'strict' sum is a 'lazy' pair of tries. We could maintain this distinction in Haskell 
using strictness annotations ( TNat is really the memo table for the flat domain 
Nj_ given by data Nat = Zero \ \Succ) but we refrain from being that pedantic. 

Second, the calculations show that tabulation is the right inverse of look- 
up. The converse can be shown using a straightforward fixpoint induction. We 
require fixpoint induction in order to cope with recursive types. That said it 
becomes clear that the case k = 0, where 0 = {_L} is the 'bottom' type, is 
missing in the derivation above. Fortunately, apply (0) (tabulate(0) if) = if holds 
trivially since 0 is the initial object in Cpo±, that is, for each type V there is a 
unique strict function of type 0 — > V. 

Example 12. The tabulation function for natural numbers is a one-liner. 

tabulateNat :: Vv.(Nat -»«)-» TNat v 

tabulateNat p = NNat (tp Zero) (tabulateNat (tp • Succ)) 

The standard toy example for memoization is the Fibonacci function. 



fib 

fib Zero 

fib (Succ Zero) 

fib (Succ (Succ n)) 



:: Nat -> Nat 

= Zero 

= Succ Zero 

= fib n -f fib (Succ n) 



1 Monoidal closure is similar to cartesian closure except that the product (here, the 
smash product) is not a categorical product but a tensor product. 
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Its time complexity can be improved from exponential to quadratic if the recur- 
sive calls are replaced by table lookups. 



Example 13. Tabulating a function of type Bin — > V is equally easy. 
tabulateBin :: \/v.(Bin —>«)—> TBin v 

tabulateBin p = NBin (p> End) (tabulateBin (p> ■ One)) (tabulateBin (p> ■ Two)) 



Example 14- Like its inverse tabulateTree requires polymorphic recursion (note 
that Xx — > e is Haskell notation for the lambda abstraction Xx.e). 

tabulateTree :: \fv.(Tree -> v) -> TTree v 
tabulateTree p = NTree (p Leaf) (tabulateTree (XI — > 

tabulateTree (Xr -» tp (Fork I r)))) □ 

Example 15. Finally, for parametric lists we obtain a 'higher-order' tabulation 
function. 

tabulateList :: Via a.(Vu.(a — > v) — > ta v) 

— > (Vw.(List a — > w) — > TList ta w) 
tabulateList tabulatea ip 

= NList (p Nil) (tabulatea (Xa — > 

tabulateList tabulatea (Xas — > tp (Cons a as)))) 

Using TList we can memoize functions that operate on lists. The following dy- 
namic programming problem, optimal matrix multiplication, may serve as an 
example. Given a sequence of matrix dimensions [do, . . . ,d n ], the problem is to 
find the least cost for multiplying out a sequence of matrices Mi * • • • * M n where 
the dimension of M, is x dj. We assume that multiplying an i x j matrix 
by an j x k matrix costs i * j * k. The following Haskell program implements a 
straightforward, but exponential solution. 

cost :: List Nat — > Nat 



| n < 1 =0 

| otherwise = minimum [cost (take (i + 1) d) 

+ d !! 0 * d !! i * d !! n 

+ cost (drop i d) \ i <— [l..n — 1]] 

where n = length d — 1 



fib 

fib Zero 

fib (Succ Zero) 

fib (Succ (Succ n)) 



Nat -> Nat 
Zero 



Succ Zero 

memo- fib n + memo- fib (Succ n) 
Nat -> Nat 

applyNat (tabulateNat fib) □ 



memo-fib 
memo-fib 



a 



cost d 
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Memoizing the recursive calls improves the complexity from exponential to poly- 
nomial in the size of the input (the modified version of cost is omitted for reasons 
of space) . 

memo-cost :: List Nat — > Nat 

memo-cost = (applyList applyNat) ((tabulateList tabulateNat) cost) 

An ad-hoc variant of this code appears in [13]. □ 

Example 16. The function memo-cost defined in the previous example maintains 
a global memo table. This comes at a considerable cost: recall that functions on 
the natural numbers are memoized using infinite lists and note that the matrix 
dimensions do, . . . , d n index these lists. A more efficient alternative both in time 
and in space is to maintain a local memo table. 



cost 
cost d 

where 

n 

c 

I * + 1 > j 
I otherwise 



memo-c 
memo-c (i,j) 



List Lnt — > Int 
memo-c (0, n) 

length d — 1 
(Nat, Nat) -» Lnt 

0 

minimum [memo-c (i,k) 

+ d !! i * d !! k * d !! j 

+ memo-c (k,j) \ k <— [i + I . . j — 1]] 

(Nat, Nat) -» Lnt 
applyNat (applyNat ( 

tabulateNat (Xi' -» tabulateNat (Xj' -» c (i',j')))) i) j 



Since the sequence of matrix dimensions d is fixed in the body of cost, sublists 
of d can be represented by pairs of list indices. Consequently, a much smaller 
memo table suffices: memo-c uses a table of type TNat (TNat Lnt) that is 
indexed by pairs of list indices (which are small) rather than by sequences of 
matrix dimensions (which may be be very large) . The resulting code corresponds 
closely to the standard dynamic programming solution, see, for instance [15]. □ 



4 Properties 

For a fixed k, the type constructor Table(k) satisfies the properties of a functor 
(it is an endo functor of Cpo±). Its functorial action on arrows is given by 

table (k) :: \fv w.(v ->«;)-> (Table {k) v ->• Table(k) w) 

table(l) ip = (f 

table(k\ + fe) <p = table(ki) tp x table^) <p 
table(k\ x ka) tp = table (hi) (table^) tp) ■ 
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The functor laws 

table(k) id = id 

table(k) (p ■ %p) = table(k) p ■ table(k) ip 

can be shown using straightforward fixpoint inductions, see, for instance [7]. 

The functions apply (k) and tabulate (k) are then natural isomorphisms be- 
tween (k — >) and Table(k). Note that the functor (k — >) is sometimes written 
(— )*. Its functorial action is postcomposition given by post ip = curry (ip ■ eval) 
where eval is function application. The naturality conditions are 

apply (k) • table(k) tp = post tp ■ apply (k) 
tabulate(k) • post p = table(k) p • tabulate(k) . 

The proofs below are based on the following pointwise variants. 

apply(k) (table(k) p t) = p ■ apply(k) t 
tabulate(k) (tp ■ %p) = table(k) p (tabulate(k) %p) 

An immediate consequence of the second naturality property is, for instance, 

tabulate(k) p = table(k) p (tabulate(k) id) . 

Thus, instead of tabulating p we can tabulate id and then map p on the re- 
sulting memo table. Since some types allow for a more efficient implementation 
of tabulate(k) id, applying the law from left to right may be an optimization. 
We prove apply(k) (table(k) ip t) = ip ■ apply(k) t by fixpoint induction on k. 
The second naturality property then follows immediately since apply (k) and 
tabulate(k) are mutually inverse. Case k = 0: the proposition holds trivially 
for strict p since polytypic functions are strict in their type arguments, that is, 
apply (0) = _L and tabulate (0) = _L. Case k = 1: 

apply (1) (table(l) ip t) 
= { definition apply(l) } 

\{).table(l) p t 
= { definition table(l) } 

XQ.pt 

= { extensionality: ipi = -02 1 — > A <^=^> ipi () = ip2 () A } 

p-(XQ.t) 
= { definition apply(l) } 

<fi ■ apply(l) t . 

Case k = k\ + fe: 



apply(ki + fe) (table(k\ + fe) p t) 
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= { definition apply(ki + k 2 ) } 

apply(ki) (outl (table(ki + k 2 ) t)) V apply(k 2 ) (outr (table(ki + k 2 ) p t)) 
= { definition table (ki + k 2 ), 

outl • (ip\ x ip 2 ) = ipi • outl and outr ■ (ip\ x ip 2 ) = ^2 • owir } 

apply(ki) (table{k\) p {outl t)) V apply(k2) (table(k 2 ) p (outr t)) 
= {ex hypothesi } 

(p • apply{k\) (outl t)) V (p • apply(k 2 ) (outr t)) 
= { coproduct fusion law: ip ■ (ipi V ip 2 ) = (ip • ipi) V (ip ■ ip 2 ) } 

p ■ (apply(ki) (outl t) V apply(k 2 ) (outr t)) 
= { definition apply(ki + k 2 ) } 

p ■ apply (h + k 2 ) t . 

Case k = ki x k 2 : 

apply(k\ x fe) (table (k\ x k 2 ) y? i) 
= { definition apply (ki x k 2 ) } 

uncurry (apply(k 2 ) ■ apply(ki) (table(ki x fc 2 ) y? i)) 
= { definition table(ki x & 2 ) } 

uncurry (apply(k 2 ) • apply(k\) (table(ki) (table(k 2 ) p) t)) 
= {ex hypothesi } 

uncurry (apply(k 2 ) ■ table(k 2 ) p • apply(k\) t) 
= {ex hypothesi } 

uncurry (post p ■ apply (k 2 ) ■ apply (ki) t) 
= { proof obligation, see below } 

p ■ uncurry (apply (ki) • apply (ki) t) 
= { definition apply (ki x k 2 ) } 

p ■ apply(k\ x k 2 ) t . 

It remains to show p> ■ uncurry f = uncurry (post p> ■ /), which is equivalent to 
curry (p> ■ uncurry /) = post p> ■ f. 

curry (p> ■ uncurry f) 
= { definition uncurry } 

curry (p ■ eval • (f x id)) 
= { curry fusion law: curry ip ■ g = curry (ip ■ (g x id)) } 

curry (p> ■ eval) ■ f 
= { definition post } 

post p ■ f 
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5 Conclusion and future work 

Memo functions make an interesting case study in polytypic programming. In im- 
plementing trie-based memo functions we have encountered kind-indexed kinds 
(TABLE), kind-indexed types (Apply), type-indexed types (Table), and type- 
indexed values (apply). It is quite remarkable that all of these concepts show up 
in a single application. 

A direction for future work suggests itself. It remains to extend memoization 
to higher-order functions. Recall that we have based tries on the law of expo- 
nentials. Unfortunately, there is no obvious way of rewriting the function space 
(ki — > k 2 ) — > v. A possible way out of this dilemma is to apply memoization 
'recursively': since ki — > k 2 = Table(ki) k 2 , we may set 

Table(ki -» k 2 ) v = Table (Table (h) k 2 ) v = Table (Table (h)) (Table(k 2 )) v 

The author is currently exploring this approach. 
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